@dloetzke: Anlässlich der Überlegung, in mehrere Actions aufzuteilen (eine je "grobem" resultType Output, Umgebungsvariable, JSON o.ä.) habe ich die resultType-Beschreibung reviewed und etwas präzisiert und damit die eine "große" Action für gut befunden. Denn die Haupt-Komplexität (das präzise zu spezifizieren) ist doch innerhalb der ResultTypes, nicht dadurch, dass eine Action mehrere ResultTypes kann.

@ChristophS-md Vielleicht verstehe ich dich falsch - aber würde sich die Aufteilung nicht gerade lohnen, wenn dadurch die Komplexität auf mehrere Actions aufgeteilt wird, statt dass die gesamte Komplexität in einer großen gesammelt ist?

Die große wäre dann sozusagen ein simpler Wrapper und die einzelnen ResultTypes sind schick modular auf mehrere Unter-Actions aufgeteilt.

@ChristophS-md Vielleicht verstehe ich dich falsch - aber würde sich die Aufteilung nicht gerade lohnen, wenn dadurch die Komplexität auf mehrere Actions aufgeteilt wird, statt dass die gesamte Komplexität in einer großen gesammelt ist?

Die große wäre dann sozusagen ein simpler Wrapper und die einzelnen ResultTypes sind schick modular auf mehrere Unter-Actions aufgeteilt.

Mir geht es nicht um die Komplexität, alle ResultTypes in einer Action zu implementieren - das finde ich übersichtlich gelöst und nicht zu komplex. (Und es macht Wiederverwendung innerhalb des Java-Code einfach, was bei mehreren Repos nicht so bequem ginge.)

Ich meine die API: Wie viele Fälle muss ich in einer einzigen action.yml beschreiben? Aufteilung hieße für mich dann, dass es gar keine Wrapper-Action geben sollte, die alle ResultTypes kann, sondern nur die einzelnen Actions read-java-properties (~ output), read-java-properties-named (~ output-named), java-properties-to-env (~ env), java-properties-to-env-named (~ env-named), java-properties-to-json (~ json), java-properties-to-json-file (~ json-file) o.ä., die alle keinen resultType-Input hätten.

Den Gewinn an Übersichtlichkeit halte ich aber für nicht so groß, dass ich dafür mehrere Repos oder mehrere Versionierungen in einem Repo in Kauf nehmen will.

Achso! Ich hatte es so verstanden, dass die Komplexität in den ResultTypes liegt.

Denn die Haupt-Komplexität (das präzise zu spezifizieren) ist doch innerhalb der ResultTypes

Mit "innerhalb" ist hier dann die Logik dahinter gemeint, welche hier übersichtlicher ist, als wenn sie aufgeteilt würde?

Man müsste auch bei einer Aufteilung der ResultTypes auf mehrere Actions nicht die Logik in jeder einzeln implementieren, man hätte daraus auch z. B. ein Monorepo mit einer Helfer-Klasse für die Logik erstellen können, die in den jeweiligen, von den Actions genutzten Klassen importiert/genutzt werden.

Aber soweit ich dich verstehe, ergibt es hier tatsächlich wenig Sinn, irgendwas aufzuteilen. Insofern war das eher eine zusätzliche Anmerkung als ein konkreter Vorschlag. :)

Mit "innerhalb" ist hier dann die Logik dahinter gemeint, welche hier übersichtlicher ist, als wenn sie aufgeteilt würde?

Übersichtlicher zusammen meinte ich auch nicht, eher beide Varianten gleich komplex. Konkret z.B. die ganze "output-named:"-Doku

<names> is a resultNameSeparator-separated list of output names of the same length as (the keySeparator-separated list) keys. The value for keys[i] is set as output <names>[i]. In order not to hide any future builtin outputs of this action, it is recommended to prefix each name with an underscore ("_"). In this mode, keys is required. Unlike "output", names are taken as-is. (This is because no official output naming rules seem to exist yet; so maybe a future user will know better how to choose valid characters than we would implement now.) The output for a missing property is set to empty. If you need to distinguish between empty an undefined properties, resultType "json" or "json-file" is recommended.

sähe in Einzel-Action read-java-properties-named noch fast genauso aus. Sie hinge nur nicht am Input resultType, den sie nicht hätte, sondern auf Action-Ebene. Für die Namen (jetzt <names>-"Parameter" innerhalb des resultType-Wertes) hätte sie dann einen Input names o.ä.

Man müsste auch bei einer Aufteilung der ResultTypes auf mehrere Actions nicht die Logik in jeder einzeln implementieren, man hätte daraus auch z. B. ein Monorepo mit einer Helfer-Klasse für die Logik erstellen können, die in den jeweiligen, von den Actions genutzten Klassen importiert/genutzt werden.

Es bliebe ja, dass man für die Versionierung der Einzel-Actions dann mehrere Tag-Namensschemata bräuchte in der Art output-1.0.0, json-1.0.3. Nicht schlimm, aber alles in allem gewinnt m.E. dann die jetzige Gesamt-Action.

Nicht schlimm, aber alles in allem gewinnt m.E. dann die jetzige Gesamt-Action.

Jop, da bin ich bei dir - ich hätte nun bis auf den Typo auch nichts mehr zu bieten - außer ein Approval. :)